¿Qué señales te hacen mover lógica de fetching fuera de `useEffect`?

La mejor forma de responder "¿Qué señales te hacen mover lógica de fetching fuera de useEffect?" en React es separar mecanismo técnico, criterio de uso y señales de revisión.

La respuesta mejora cuando explicas qué parte del problema resuelves ahora con asincronía en React para "Qué señales te hacen mover lógica de fetching fuera de useEffect", qué dejas derivado en efectos y cómo detectarías pronto que la solución empieza a quedarse corta.

Qué evalúa el entrevistador

• Si distingues qué parte de "Qué señales te hacen mover lógica de fetching fuera de useEffect" pertenece a asincronía y cuál debería resolverse en efectos.
• Si conviertes la respuesta en criterios observables: límites claros, impacto en el mantenimiento y forma de detectar regresiones.
• Si sabes ubicar efectos, limpiezas, cancelación y propagación de errores sin contaminar la parte declarativa del código.

Respuesta sólida

• Distingue qué parte puede seguir siendo pura y qué parte necesita sincronizarse con el mundo exterior.
• Describe cómo controlarías suscripciones, cancelación, reintentos o cierre de recursos para que el componente no acumule efectos zombis.
• Si hay asincronía, aclara qué harías con estados intermedios, errores y cambios rápidos de entrada.

Compromisos y errores comunes

• El error habitual es usar efectos para derivar datos que podrían calcularse de forma pura o para tapar un mal diseño de dependencias.
• Sin cancelación ni limpieza es muy fácil dejar trabajo en vuelo, respuestas tardías o cierres obsoletos.

Ejemplo de código

Este fragmento sirve para bajar "Qué señales te hacen mover lógica de fetching fuera de useEffect" a código ejecutable y mostrar qué decisiones conviene hacer explícitas cuando asincronía empieza a cruzarse con efectos.

import { useEffect, useState } from 'react';

export function UserPanel({ userId }: { userId: string }) {
  const [user, setUser] = useState<{ name: string } | null>(null);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    const controller = new AbortController();

    async function loadUser() {
      try {
        const response = await fetch(`/api/users/${userId}`, { signal: controller.signal });
        if (!response.ok) throw new Error('No se pudo cargar el usuario');
        setUser(await response.json());
      } catch (cause) {
        if (!(cause instanceof DOMException && cause.name === 'AbortError')) {
          setError('No hemos podido cargar los datos.');
        }
      }
    }

    void loadUser();
    return () => controller.abort();
  }, [userId]);

  if (error) return <p>{error}</p>;
  return <p>{user?.name ?? "Cargando..."}</p>;
}

Fíjate en que el ejemplo deja claras las fronteras de "Qué señales te hacen mover lógica de fetching fuera de useEffect", nombra los estados relevantes y evita trabajo implícito que luego cuesta depurar.

Ejemplo o caso real

Un caso creíble para "¿Qué señales te hacen mover lógica de fetching fuera de useEffect?" aparece cuando una funcionalidad de React mezcla asincronía con efectos y el equipo empieza a tocar demasiados puntos para un cambio pequeño. Ahí conviene probar la solución sobre una pantalla o flujo acotado, medir si reduce fricción y solo después extender el patrón.

Frase corta de entrevista

En "Qué señales te hacen mover lógica de fetching fuera de useEffect" me interesa más mantener una fuente de verdad clara y una validación honesta que sonar sofisticado.